@oclif/[email protected] crashes at import time on Node 20+ (reads
module.parent.filename, and module.parent is undefined under the modern
module loader). No 2.x release fixes this without also moving to
@oclif/core@3, so bump both together.

- @oclif/core 1.21.0 -> ^3.27.0, @oclif/test 2.2.13 -> ^3.2.15,
  @oclif/plugin-help 5 -> ^6, oclif (dev) 3 -> ^4
- migrate the inject command's static args from the array form to the
  Args.string({...}) object map required by core 3, and read positional
  args off argv as string[]
- engines.node 18 -> >=20

The workflow failed every job at setup-node: cache:yarn shelled out to
global yarn 1.x against a repo pinned to [email protected] via corepack, so
'yarn cache dir' errored before install ran. It also carried a corrupted
matrix value (20hashhas) and hardcoded node-version:'18', ignoring the
matrix entirely.

- enable corepack before setup-node so yarn 3.4.1 resolves
- wire the matrix node_version/architecture into setup-node instead of
  the hardcoded 18
- drop EOL node (14/16/18/19), test on 20/22/24/26
- yarn install --frozen-lockfile -> --immutable (yarn 3 flag)
- checkout@v3/setup-node@v3 -> @v4, add fail-fast: false

The repo builds only under the node-modules linker, but .yarnrc.yml was
gitignored, so CI never received it and fell back to yarn's default PnP
linker -- which nx cannot run under (nx's task runner and native binary
loading are incompatible with PnP's virtual filesystem, confirmed on nx
15 through 23). Track .yarnrc.yml so CI and every contributor use the
linker that actually builds the monorepo.

setup-node's cache:'yarn' invokes 'yarn cache dir' during the action
using the runner's global yarn 1.x, before the corepack shim is active
on windows -- which errors on the [email protected] packageManager pin. Every
windows matrix job failed there while ubuntu/macos passed. Drop the
built-in yarn cache so nothing calls yarn until the corepack-managed
3.4.1 is active; install just fetches fresh.

corepack enable ran BEFORE setup-node, so setup-node reinstalled node
and the global yarn 1.x shim shadowed corepack again -- every windows
job still hit the [email protected] packageManager error (ubuntu/macos happened
to resolve corepack anyway). Move corepack enable after setup-node and
add 'corepack prepare [email protected] --activate' so the pinned yarn is the
active shim before install runs, on all platforms.

corepack's activated shim did not survive into the next workflow step on
windows: 'corepack prepare [email protected] --activate' succeeded, but the
following step's fresh pwsh session resolved the runner's global
yarn 1.22.22 again (its yarn.cmd shadows the corepack shim on PATH).

Collapse corepack activation + install/build/lint into a single
'shell: bash' step so the pinned yarn is active in the same session that
runs yarn, and use git-bash on windows where the shim resolves reliably.

Node 26's bundled corepack fails 'prepare --activate' on windows while
20/22/24 pass with identical steps; Node 26 is not LTS. Mark just that
matrix combo experimental via a matrix include and gate the job's
continue-on-error on it, so the combo still runs and stays visible but
does not block the workflow.